home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 679 < prev    next >
Internet Message Format  |  1994-08-27  |  3KB
  1. From: Mark.Baker@mettav.exnet.com (Mark Baker)
  2. Date: 01 Jul 94  19:47:36
  3. Message-Id: <UUCP.773202088@mettav>
  4. Subject: Re: Dialog Box Proposal Part 1
  5. To: gem-list@world.std.com (gem-list@world.std.com)
  6. Precedence: bulk
  7.  
  8. Michael:
  9.  > In your proposal, you make many suggestions.  Will you be making the
  10.  > source code to LTMF-2 available to the developers on this list?  (Myself,
  11.  > I'm just generally curious how the program does what it does.)
  12.  
  13. If he wants all these extra featurs to be mandatory he'd better give us an
  14. example of how to do them :)
  15.  
  16.  >> If the mouse is placed over an editable text field, the mouse MUST
  17.  >> change to a TEXT CURSOR while the mouse is over it.  It must be changed
  18.  >> back to its original form when moved away.
  19.  >
  20.  > You sure do like that word; "MUST".  Actually, I disagree with this as
  21.  > well.  A nice feature, but hardly essential.
  22.  
  23. And it needs a lot of coding effort. Nice, but we don't want the standard to be
  24. too difficult to implement or no-one will bother using it.
  25.  
  26. Warwick:
  27.  > Normal TOS does too.  NOWHERE does GEM insist that you treat a TOPPED
  28.  > message as something that MUST top your window.  Events in GEM are
  29.  > advisory only.  When GEM++ receives a TOPPED message, it uses the mouse
  30.  > coordinates of the message as a click.  If the click is not on anything
  31.  > interesting, it just does a TOP, otherwise, it leaves the window
  32.  > untopped and performs the operation.  Any program that has a Toolbox and a
  33.  > Document Window appreciates this behaviour.  PageStream and Calamus do it,
  34.  > of course, and I noticed that the new version of Kandinsky does also.
  35.  
  36. For toolbox windows this is very useful but I don't like it used for dialogues
  37. or any other window, IMO a left click should always top these, with both
  38. buttons required to use an untopped window (like in the desktop). Does everyone
  39. agree with me that the mswindows behaviour of topping _and_ activating a button
  40. is undesirable?
  41.  
  42. One problem can be that now with aes 4 letting you use window gadgets without
  43. topping it gets very hard _to_ top a window :)
  44.  
  45.  > The top-window-is-active model is tiresome.  We have to put up with it
  46.  > for keyboard in most cases (although GEM++ gets around this by allowing
  47.  > click-to-type on backgrounded editable text fields).
  48.  
  49. Obviously you want keyboard input to go to only one window, and having it the
  50. top window is easiest for the user (I know the active window and top window are
  51. different on some systems, but this is confusing for the user, particularly for
  52. a user used to the atari). BTW I don't like the way text entry is modal in
  53. GEM++.
  54.  
  55.  
  56.  
  57.